主题
多版对比
几乎互补零重叠：二哥整篇在答「各 benchmark 测什么」，JavaGuide 整篇在答「为什么公开 benchmark 不够用、怎么自建」。拼起来才是完整答案。
二哥的干货是机制细节：SWE-bench 出自普林斯顿 NLP——真实 GitHub Issue + 整个仓库，跑通测试才算对，判分是确定性的；初版两千多题全 Python，后续版本扩语言、拉大改动量防背题；Terminal-Bench 在 Docker 沙箱里跑终端任务；GPQA 是研究生级的「搜索引擎查不到」问答。这些「怎么判分」的细节正是面试时证明「我真了解」的部分。一处硬伤：他把 SWE-bench 的 SWE 拆成两个全称并存，正确的是 Software Engineering。
JavaGuide 的核心判断：公开 benchmark 只能粗筛——榜单任务和数据固定，覆盖不了脏输入（错别字、截图、多语言混杂），更覆盖不了业务规则；低频高风险路径（合同漏条款、退款流程答错、危险命令）会被平均分掩盖；「说得像成功」不等于「真的成功」，要看 Outcome（退款单是否真的创建了）。自建评测的分工：规则判硬错误 → LLM-as-Judge 评语义 → 人工校准高风险，用例要带预期结果和类别，接进 CI 做回归。
小林：补了机制与落地两层。机制上点名 benchmark 的系统性缺陷是数据污染（预训练背过题、榜单虚高），应对是 LiveBench 类持续换题 + 自建业务集；榜单地图一句话可背：MMLU 综合知识、SWE-bench 真实 Issue、GPQA 防搜索引擎、τ-bench 看工具与稳定性。落地数字最具体：业务黄金集 50-200 条真实请求采样、LLM 裁判抽样 10-20% 人工校准；RAGAS 四指标带目标值（Faithfulness>0.8、Answer Relevancy>0.8、Context Recall>0.7），每条指标低都映射到具体优化方向（换 Embedding / 加多路召回 / 强 Rerank）。Agent 评测四层（工具 → 轨迹 → 端到端 → 线上），τ-bench 的 pass^k（连续 k 次都成功）区别于 pass@k，裁判有位置/篇幅/自我偏好三种偏差要校准；安全约束是硬门禁，不能被综合分加权平均掉。
结论：三方正好三层——二哥答「榜单测什么」、JavaGuide 答「为什么不够用、怎么自建」、小林答「指标怎么定阈值、Agent 怎么分层评」。
最优题解
先说 benchmark 在测什么：代码类像 SWE-bench 是真实 GitHub Issue 加整个仓库，判分不看回答像不像、看测试跑不跑得通，这是它可信的原因；终端类在沙箱里考真实操作；问答类用「搜索引擎查不到」的题防背诵。它们适合选型粗筛：能力下限一测便知。
但上线决策不能只看榜单：榜单任务固定，覆盖不了脏输入和业务规则；低频高风险路径会被平均分掩盖；而且榜单分数和「我的业务场景表现」不是一回事。所以自建评测：攒真实样例的 Golden Set，规则判硬错误、模型当裁判评语义质量、高风险路径人工复核；判分要看业务结果而不只是「回答像不像对的」，并把评测接进 CI，每次改 Prompt、换模型、动检索参数都跑回归。
追问链
追问：LLM-as-Judge 不可靠怎么办？ 参考答：裁判也要校准——抽样和人工评分对齐，给评分标准和少量锚定样例，输出要带理由和置信度；高风险路径不信裁判，人工复核。
追问：评测集怎么防止被「背题」？ 参考答：一是像新版 benchmark 那样控制题目传播、从零重编；二是业务上定期从真实流量里换血，线上只保留少量锚定题做版本对齐。
我的理解
这题的最优结构是「先答机制再答局限再答自建」——只会背榜单名字是下乘，说得出 SWE-bench「跑通测试才算对」的判分机制是中乘，接上「平均分掩盖低频高风险 + Outcome 判断」才是能落地的答案。JavaGuide 拒引具体跑分、二哥整篇是跑分的风格对撞也提醒我：引用跑分必须带时间和版本，否则不如不引。